Jetson AGX Orin 파이썬 패키지 버전 관리 (2025–09-25)

1. 서론: Jetson AGX Orin 환경의 특수성과 파이썬 패키지 관리의 중요성

NVIDIA Jetson AGX Orin은 단순한 ARM aarch64 아키텍처 기반의 싱글 보드 컴퓨터가 아니다. 이는 고도로 통합된 하드웨어 가속 스택을 갖춘 임베디드 AI 컴퓨팅 플랫폼으로서, 그 본질을 정확히 이해하는 것이 파이썬 패키지 관리 전략 수립의 첫걸음이다. Jetson 플랫폼의 핵심은 NVIDIA JetPack SDK에 의해 관리되는 소프트웨어 생태계에 있다. JetPack은 Linux for Tegra(L4T) 운영체제, CUDA Toolkit, cuDNN, TensorRT, 멀티미디어 API 등 하드웨어 가속기와 직접 상호작용하는 필수 라이브러리들의 특정 버전을 포함하고 있다.1 이러한 구성 요소들은 개별적으로 존재하는 것이 아니라, 최적의 성능과 안정성을 보장하기 위해 서로 긴밀하게 맞물려 동작하도록 설계되었다.

이러한 Jetson 환경의 특수성은 파이썬 패키지 관리에 있어 근본적인 도전 과제를 제시한다. 바로 ‘강한 결합(Tight Coupling)’ 문제이다. Jetson에서 고성능 AI 애플리케이션을 구동하기 위해 사용되는 핵심 파이썬 패키지들, 예를 들어 PyTorch, TensorFlow, 또는 nvidia-tensorrt와 같은 라이브러리들은 일반적인 Python Package Index(PyPI) 저장소에서 제공되는 패키지와는 본질적으로 다르다. 이 패키지들은 Jetson의 Tegra SoC 아키텍처와 특정 JetPack 버전에 포함된 CUDA, cuDNN, TensorRT 버전에 완벽하게 호환되도록 NVIDIA에 의해 특별히 컴파일되고 패키징된 바이너리다.2 예를 들어, PyPI에서

pip install torch 명령으로 설치되는 공식 PyTorch 휠(wheel)은 대부분 x86 아키텍처와 범용 CUDA 버전을 대상으로 빌드되었기 때문에, Jetson의 통합 GPU(iGPU) 및 L4T 커널 드라이버와 호환되지 않아 GPU를 인식하지 못하는 문제(torch.cuda.is_available()가 False를 반환)를 일으킨다.2

이처럼 Jetson에서의 패키지 관리는 단순한 파이썬 라이브러리 버전 관리 문제를 넘어, 하드웨어-소프트웨어 인터페이스 전체의 무결성을 관리하는 시스템 통합의 문제로 확장된다. pip install과 같은 단순한 명령 하나가 JetPack이 세심하게 구성해 놓은 소프트웨어 스택의 균형을 깨뜨릴 수 있는 잠재적 위험 요소가 되는 것이다. 따라서, 주먹구구식의 패키지 관리는 예측 불가능한 의존성 충돌, 성능 저하, 심각하게는 하드웨어 가속 기능의 완전한 비활성화와 같은 치명적인 결과를 초래할 수 있다. 개발 환경의 안정성, 여러 장치와 개발자 간의 환경 일관성을 보장하는 재현성(reproducibility), 그리고 효율적인 팀 협업을 위해서는 Jetson의 생태계를 존중하고 그 위에서 동작하는 체계적인 버전 관리 전략을 수립하는 것이 절대적으로 필수적이다.

2. 기본 시스템 파이썬 환경의 한계와 위험성

Jetson AGX Orin을 처음 설정하고 나면 시스템 전역에 파이썬 인터프리터가 설치되어 있다. 가장 간단하고 직관적인 방법은 이 시스템 파이썬 환경에 직접 필요한 패키지를 설치하는 것이지만, 이는 단기적인 편의성을 위해 장기적인 안정성과 보안을 희생하는 매우 위험한 접근 방식이다.

2.1 글로벌 site-packages의 문제점

시스템 전역에 패키지를 설치하는 것은 모든 프로젝트가 단 하나의 site-packages 디렉토리를 공유하게 됨을 의미한다. 이는 필연적으로 “의존성 지옥(Dependency Hell)“이라 불리는 고전적인 문제로 이어진다. 예를 들어, 로봇의 자율 주행을 담당하는 프로젝트 A가 numpy==1.19.5 버전을 요구하고, 비전 데이터를 분석하는 프로젝트 B는 최신 기능을 사용하기 위해 numpy==1.23.1 버전을 필요로 한다고 가정해 보자. 글로벌 환경에서는 이 두 가지 버전 중 하나만 설치할 수 있으므로, 두 프로젝트를 동시에 만족시키는 것은 원천적으로 불가능하다. 하나의 프로젝트를 위해 패키지를 업그레이드하면 다른 프로젝트가 망가지는 상황이 반복되며, 이는 개발 효율성을 심각하게 저하시키고 예측 불가능한 런타임 오류의 원인이 된다.6

2.2 sudo pip install 사용의 치명적 위험 심층 분석

글로벌 환경에 패키지를 설치하기 위해서는 일반적으로 sudo pip install 명령어를 사용하게 되는데, 이는 Jetson과 같은 임베디드 시스템에서 잠재적으로 가장 파괴적인 결과를 초래할 수 있는 행위 중 하나다. 그 위험성은 크게 두 가지 측면에서 분석할 수 있다.

첫째, 심각한 보안 취약점을 노출시킨다. sudo pip install 명령어는 PyPI에서 다운로드한 패키지에 포함된 setup.py 스크립트를 시스템의 최고 관리자인 root 권한으로 실행한다. PyPI는 커뮤니티 기반 저장소로, 원칙적으로 누구나 패키지를 업로드할 수 있으며 모든 패키지가 철저한 보안 감사를 거치는 것은 아니다. 만약 공격자가 악의적인 코드를 숨겨놓은 패키지를 PyPI에 업로드하고, 개발자가 이를 인지하지 못한 채 sudo 명령으로 설치한다면, 이는 시스템의 모든 파일과 프로세스에 접근할 수 있는 root 권한을 공격자에게 스스로 넘겨주는 것과 같다.6

둘째, 시스템 패키지 손상을 야기할 수 있다. Jetson의 L4T를 포함한 대부분의 리눅스 배포판은 운영체제의 핵심 기능과 시스템 유틸리티를 구동하기 위해 특정 버전의 파이썬 라이브러리에 의존한다. 예를 들어, 시스템 업데이트 관리자나 네트워크 설정 도구 등이 내부적으로 특정 버전의 PyYAML이나 cryptography 라이브러리를 사용하고 있을 수 있다. 이때 개발자가 sudo pip install --upgrade와 같은 명령으로 해당 라이브러리를 임의의 버전으로 변경하면, 시스템 유틸리티가 더 이상 정상적으로 동작하지 않게 될 수 있다. 최악의 경우, 시스템 부팅 과정에 필수적인 스크립트가 의존하는 라이브러리가 손상되어 Jetson 장치가 부팅 불능 상태, 즉 “벽돌(brick)“이 될 수도 있다.6

2.3 Jetson 환경에서의 증폭된 위험

이러한 위험은 일반적인 데스크톱 환경보다 Jetson과 같은 임베디드 시스템에서 훨씬 더 증폭된다. 데스크톱에서 운영체제가 손상되면 데이터를 백업하고 OS를 재설치하면 되지만, 원격지의 공장, 농장, 또는 자율주행 로봇에 배포된 Jetson이 소프트웨어 손상으로 인해 네트워크 접속 불능 상태가 되면 문제는 차원이 달라진다. 이는 단순한 개발의 불편함을 넘어 심각한 운영 실패로 이어진다. 장비를 물리적으로 회수하여 전체 시스템을 다시 플래시(re-flash)해야 하는 상황은 막대한 시간과 비용을 초래하며, 이는 미션 크리티컬 애플리케이션에서는 결코 용납될 수 없는 리스크다.10

과거 NVIDIA의 SDK Manager 설치 스크립트조차 sudo pip를 사용하여 TensorFlow 의존성을 설치했던 사례가 있으며, 이로 인해 사용자 홈 디렉토리 내의 .cache/pip 디렉토리 소유권이 root로 변경되어 이후 일반 사용자 권한으로 pip를 실행할 때마다 권한 관련 경고가 발생하는 혼란을 야기하기도 했다.11 이는 Jetson 생태계의 복잡성과 시스템 전역 환경을 수정하는 행위를 얼마나 신중하게 피해야 하는지를 명확히 보여준다. 따라서 “

sudo pip를 사용하지 말라“는 권고는 단순한 모범 사례를 넘어, 임베디드 시스템의 안정성과 신뢰성을 확보하기 위한 최우선적인 운영 리스크 관리 원칙으로 받아들여야 한다.

3. 표준 격리 도구: venv를 활용한 가상 환경 관리

시스템 전역 환경의 위험성을 피하기 위한 가장 기본적인 해결책은 파이썬 프로젝트별로 독립적인 실행 환경을 제공하는 가상 환경(virtual environment)을 사용하는 것이다. 파이썬 3.3 버전부터 표준 라이브러리에 포함된 venv 모듈은 이를 위한 가볍고 효율적인 도구다.

3.1 venv 기본 사용법

venv의 핵심 아이디어는 각 프로젝트 폴더 내에 해당 프로젝트만을 위한 파이썬 패키지 디렉토리(site-packages)와 실행 파일을 격리된 형태로 생성하는 것이다. 이를 통해 프로젝트 간의 의존성 충돌을 원천적으로 방지하고, 프로젝트의 이식성과 재현성을 높일 수 있다.

venv의 기본적인 사용 절차는 다음과 같다.

1. 가상 환경 생성: 프로젝트 디렉토리에서 다음 명령을 실행하여 my-project-env라는 이름의 가상 환경을 생성한다.

Bash

python3 -m venv my-project-env

2. 가상 환경 활성화: 생성된 환경을 현재 셸 세션에서 활성화한다. 활성화되면 셸 프롬프트 앞에 (my-project-env)와 같이 환경 이름이 표시된다.

Bash

source my-project-env/bin/activate

3. 패키지 설치: 활성화된 상태에서 pip를 사용하면 모든 패키지는 시스템 전역이 아닌, 현재 가상 환경 내의 site-packages 디렉토리에 설치된다.

Bash

pip install numpy pandas torch

4. 의존성 고정 및 재현: 프로젝트에 필요한 모든 패키지 설치가 완료되면, pip freeze 명령을 사용하여 현재 환경에 설치된 패키지와 그 버전을 requirements.txt 파일로 저장한다. 이 파일은 프로젝트의 의존성을 명시적으로 문서화하는 역할을 한다.

Bash

pip freeze > requirements.txt

다른 개발자나 다른 시스템에서 이 프로젝트 환경을 동일하게 복제하려면, 새로운 가상 환경을 생성하고 활성화한 뒤 다음 명령을 실행하기만 하면 된다.12

Bash

pip install -r requirements.txt

3.2 Jetson 특화 주제: --system-site-packages 플래그의 딜레마

표준적인 venv 사용법은 Jetson 환경에서 하나의 중요한 문제에 직면한다. JetPack SDK를 통해 시스템에 설치되는 하드웨어 가속 라이브러리들(예: apt로 설치된 CUDA 지원 OpenCV, TensorRT 파이썬 바인딩 등)은 시스템 전역 site-packages(/usr/lib/python3.8/dist-packages 등)에 위치한다. 기본적으로 venv는 이 디렉토리에 접근할 수 없으므로, 가상 환경 내에서는 이러한 핵심 라이브러리들을 import 할 수 없다.

이 문제를 해결하기 위해 venv는 --system-site-packages라는 플래그를 제공한다. 이 플래그를 사용하여 가상 환경을 생성하면, 해당 환경은 자체 site-packages 디렉토리뿐만 아니라 시스템 전역 site-packages 디렉토리에도 접근 권한을 갖게 된다.13

Bash

python3 -m venv my-jetson-env --system-site-packages

이 방식은 Jetson 개발 초기에 매우 실용적인 해결책처럼 보인다. 복잡한 빌드 과정 없이 이미 시스템에 최적화된 NVIDIA 라이브러리들을 가상 환경 내에서 즉시 사용할 수 있게 해주며, 디스크 공간도 절약된다.14 하지만 이 편의성은 심각한 대가를 치른다.

--system-site-packages 플래그는 가상 환경의 핵심 철학인 ’완전한 격리’를 깨뜨리는 행위이기 때문이다.

이 플래그를 사용하면 프로젝트는 requirements.txt에 명시된 의존성 외에, 시스템 상태라는 암묵적이고 문서화되지 않은 의존성을 추가로 갖게 된다. pip freeze는 시스템 레벨의 패키지를 기록하지 않으므로, 이 requirements.txt 파일만으로는 다른 장비에서 개발 환경을 완벽하게 복제하는 것이 불가능해진다. 만약 호스트 시스템에서 apt를 통해 관련 패키지를 업데이트하거나 제거하면, 가상 환경의 동작은 개발자의 의도와 상관없이 예기치 않게 변경되거나 실패할 수 있다.14

결론적으로, --system-site-packages는 가상 환경을 진정한 격리 공간이 아닌, 시스템 환경 위에 덧씌워진 ‘델타(delta)’ 또는 ’오버레이(overlay)’로 만들어 버리는 ’새는 추상화(leaky abstraction)’다. 이는 장기적으로 프로젝트의 안정성과 이식성을 심각하게 저해한다. 따라서 이 방법은 개인적인 빠른 프로토타이핑이나 일회성 실험에는 유용할 수 있으나, 재현성이 생명인 연구, 여러 개발자가 참여하는 팀 프로젝트, 또는 안정적인 배포가 필수적인 프로덕션 환경에서는 절대적으로 피해야 할 접근 방식이다.

4. 고급 패키지 및 환경 관리: Conda (Miniforge) 도입

venv가 파이썬 패키지를 격리하는 훌륭한 도구임은 분명하지만, 그 한계 또한 명확하다. venv는 파이썬 인터프리터 자체의 버전을 관리할 수 없으며, C/C++로 작성된 외부 라이브러리 의존성을 직접 처리하지 못한다. 이러한 한계를 극복하기 위해 등장한 것이 바로 Conda다. Conda는 파이썬 패키지뿐만 아니라, 파이썬 인터프리터(예: Python 3.8, 3.10), 그리고 NumPy, SciPy 등이 의존하는 MKL, OpenBLAS와 같은 C/C++ 라이브러리까지 포함하는 포괄적인 ‘환경’ 관리자다.17

4.1 Jetson을 위한 Miniforge

전체 Anaconda 배포판은 수백 개의 과학 계산 패키지를 포함하고 있어 용량이 크고, 주로 x86 아키텍처를 중심으로 지원된다. Jetson AGX Orin과 같은 리소스가 제한적인 임베디드 aarch64 시스템에는, Conda의 핵심 기능만을 담고 커뮤니티 기반의 conda-forge 채널을 기본으로 사용하는 경량 설치 프로그램인 Miniforge가 최적의 선택이다.17

conda-forge는 다양한 아키텍처를 지원하는 데 중점을 두므로 aarch64용 패키지를 찾기에 용이하다.19

4.2 Miniforge 설치 상세 가이드

Jetson AGX Orin에 Miniforge를 설치하는 과정은 다음과 같다.

1. 설치 스크립트 다운로드: 터미널을 열고 wget 또는 curl 명령어를 사용하여 aarch64용 최신 Miniforge 설치 스크립트를 다운로드한다.

Bash

wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-aarch64.sh

19

2. 설치 스크립트 실행: 다운로드한 스크립트에 실행 권한을 부여하고 bash로 실행한다. -b (batch) 옵션은 사용자 입력 없이 자동으로 설치를 진행하고, -p 옵션은 설치 경로를 지정한다.

Bash

bash Miniforge3-Linux-aarch64.sh -b -p $HOME/miniforge3

20

3. Conda 초기화 및 셸 설정: 설치된 Conda를 사용하기 위해 셸 환경을 초기화한다. 이 과정은 .bashrc 파일에 필요한 설정을 추가한다.

Bash

source $HOME/miniforge3/bin/activate
conda init bash

19

4. 터미널 재시작: 터미널을 닫고 다시 열면, 셸 프롬프트 앞에 (base)라는 표시가 나타난다. 이는 Conda의 기본 환경이 성공적으로 활성화되었음을 의미한다.

4.3 Conda 환경에서의 JetPack 호환성: 양날의 검

Conda의 가장 강력한 기능 중 하나는 conda install cudatoolkit=11.8과 같이 특정 버전의 CUDA 툴킷을 Conda 환경 내에 직접 설치할 수 있다는 점이다. 이는 개발 환경을 호스트 시스템의 JetPack 버전으로부터 분리할 수 있다는 매력적인 가능성을 제시한다. 예를 들어, 현재 JetPack이 CUDA 11.4를 제공하지만, 최신 PyTorch 버전을 사용하기 위해 CUDA 11.8이 필요한 경우, Conda를 사용하면 이 문제를 해결할 수 있을 것처럼 보인다.3

하지만 이는 매우 위험한 양날의 검이다. Conda 환경 내에 설치된 사용자 공간(user-space)의 CUDA 라이브러리는 결국 호스트 시스템의 L4T 커널에 설치된 커널 모드(kernel-mode) 드라이버와 통신해야 한다. 만약 Conda 환경의 CUDA 버전(예: 11.8)과 호스트 커널 드라이버가 기대하는 CUDA 버전(예: 11.4) 사이에 호환성 불일치가 발생하면, 이는 파이썬 레벨의 의존성 오류보다 훨씬 더 디버깅하기 어려운 심층적인 런타임 오류(예: CUDA error: invalid argument)를 유발할 수 있다.23

이러한 불일치는 PyTorch가 CUDA 함수를 호출할 때 발생한다. 사용자 공간의 11.8 라이브러리가 커널 모드 드라이버에게 특정 API 호출을 보내면, 11.4 버전에 맞춰진 드라이버는 이 호출을 이해하지 못하고 오류를 반환하는 것이다. 이처럼 Conda는 유연성을 제공하는 대가로, 잘 정의된 JetPack 스택의 호환성 문제를 훨씬 더 복잡하고 미묘한 사용자 공간/커널 공간 드라이버 인터페이스의 호환성 문제로 전환시킨다. 따라서 Conda는 Jetson의 하부 시스템 구조에 대한 깊은 이해를 가진 전문가에게는 강력한 도구가 될 수 있지만, 이러한 복잡성을 인지하지 못하는 사용자에게는 예측 불가능한 문제의 근원이 될 수 있다.

5. 최상의 격리 및 재현성: Docker 컨테이너 활용 전략

venv와 Conda가 애플리케이션의 ’환경’을 격리하는 데 중점을 둔다면, Docker는 한 단계 더 나아가 애플리케이션과 그 환경 전체를 OS 레벨에서 격리하는 패러다임 전환을 제시한다. Docker는 애플리케이션 구동에 필요한 모든 것—코드, 런타임, 시스템 도구, 라이브러리, 설정—을 “컨테이너“라는 가볍고 이식 가능한 독립된 패키지로 묶는다. 이는 Jetson 개발에서 최고의 격리 수준과 완벽한 재현성을 달성하기 위한 가장 강력하고 현대적인 방법이다.

5.1 NVIDIA NGC 컨테이너 생태계

NVIDIA는 자사의 GPU Cloud(NGC) 카탈로그를 통해 Jetson 플랫폼에 최적화된 다양한 Docker 컨테이너를 공식적으로 제공하여 개발자들이 복잡한 환경 설정 없이 즉시 AI 개발에 착수할 수 있도록 지원한다.

• l4t-base: Jetson의 L4T 사용자 공간 라이브러리(멀티미디어, GStreamer 등)의 최소한의 집합을 포함하는 가장 기본적인 이미지다. 커스텀 환경 구축의 시작점으로 사용된다.1

• l4t-cuda / l4t-tensorrt: l4t-base 위에 CUDA 및 TensorRT 런타임을 각각 포함시킨 이미지로, 하드웨어 가속 애플리케이션 개발의 기반이 된다.24

• l4t-pytorch / l4t-tensorflow: PyTorch나 TensorFlow와 같은 주요 딥러닝 프레임워크가 JetPack 버전에 맞춰 사전 설치 및 최적화된 이미지다.26

• l4t-ml: 위 프레임워크뿐만 아니라 scikit-learn, scipy, pandas, JupyterLab 등 데이터 과학 및 머신러닝에 필요한 거의 모든 도구를 포함하는 올인원 개발 환경 이미지다.28

5.2 JetPack 버전과 컨테이너 태그 매칭의 중요성

NGC에서 제공하는 L4T 컨테이너들은 특정 JetPack/L4T 릴리스를 기반으로 빌드되고 테스트된다. 따라서 컨테이너를 사용할 때 가장 중요한 원칙은 컨테이너 이미지의 태그를 호스트 Jetson에 설치된 JetPack/L4T 버전과 정확히 일치시키는 것이다. 예를 들어, 호스트 시스템이 JetPack 5.1 (L4T R35.2.1)이라면, 반드시 nvcr.io/nvidia/l4t-ml:r35.2.1-py3와 같이 r35.2.1 태그가 붙은 이미지를 사용해야 한다. 버전이 일치하지 않으면 컨테이너가 호스트의 드라이버와 통신하는 과정에서 예기치 않은 오류가 발생할 수 있다.26

특히, JetPack 4와 JetPack 5 사이에는 컨테이너 작동 방식에 근본적인 변화가 있었다. JetPack 4 환경에서는 컨테이너가 실행될 때 호스트 시스템의 CUDA, cuDNN, TensorRT 라이브러리를 컨테이너 내부로 마운트하여 사용했다. 반면, JetPack 5부터는 이러한 핵심 라이브러리들이 모두 컨테이너 이미지 내부에 포함되는 방식으로 변경되었다.29 이 변화는 컨테이너의 이식성과 독립성을 극대화하여, “내 PC에서는 잘 됐는데“와 같은 문제를 원천적으로 차단한다. 하지만 이미지의 크기가 커지고, 호스트 L4T 버전과의 정확한 태그 매칭이 더욱 중요해지는 결과를 낳았다.

5.3 dusty-nv/jetson-containers를 활용한 자동화

NVIDIA의 엔지니어인 Dusty Franklin이 관리하는 dusty-nv/jetson-containers GitHub 프로젝트는 Jetson에서 Docker 컨테이너를 빌드하고 실행하는 과정을 획기적으로 간소화하는 강력한 스크립트와 도구 모음을 제공한다.31

• autotag 스크립트: 현재 시스템의 L4T 버전을 자동으로 감지하여 NGC 또는 로컬에 있는 가장 호환성 높은 컨테이너 이미지 태그를 찾아주는 매우 유용한 도구다. 이를 통해 개발자는 복잡한 버전 번호를 외울 필요 없이 항상 올바른 컨테이너를 실행할 수 있다.

Bash

jetson-containers run $(autotag l4t-pytorch)

31

• 모듈식 빌드 시스템: ROS2, PyTorch, Transformers 라이브러리가 모두 포함된 커스텀 컨테이너가 필요하다면, 다음과 같이 간단한 명령 한 줄로 빌드할 수 있다.

Bash

jetson-containers build --name=my_ros_ml_container ros:humble-desktop pytorch transformers

31

5.4 Docker를 통한 개발 패러다임의 전환

Jetson에서 Docker를 채택하는 것은 단순히 더 나은 격리 도구를 선택하는 것을 넘어, 개발 철학 자체를 현대적인 MLOps/DevOps 패러다임으로 전환하는 것을 의미한다. Dockerfile은 더 이상 수동으로 수행되던 환경 설정 과정을 코드(Infrastructure-as-Code)로 명시적으로 정의하는 설계도가 된다. 이 Dockerfile과 애플리케이션 코드를 함께 버전 관리 시스템(예: Git)으로 관리하면, 개발 환경 전체가 버전 관리되는 불변의(immutable) 아티팩트가 된다.

이러한 접근 방식은 CI/CD(지속적 통합/지속적 배포) 파이프라인 구축을 가능하게 한다. 코드 변경이 있을 때마다 CI 서버는 자동으로 Dockerfile을 빌드하여 테스트를 수행하고, 테스트를 통과한 이미지를 레지스트리에 푸시한다. 수십, 수백 대의 Jetson 장치에 애플리케이션을 배포하는 것은 각 장치에서 docker pull 및 docker run 명령을 실행하는 것으로 단순화된다. 모든 장치가 정확히 동일한 소프트웨어 환경에서 동작함을 보장받을 수 있으므로, 배포의 신뢰성과 확장성이 극대화된다. 이는 Jetson 플랫폼을 단순한 개발 보드에서 전문적인 프로덕션 플랫폼으로 격상시키는 핵심적인 전략적 이점을 제공한다.

6. 종합 분석 및 상황별 최적 관리 방안 권고

지금까지 Jetson AGX Orin에서 파이썬 패키지를 관리하기 위한 세 가지 주요 방법론—venv, Conda, Docker—을 심층적으로 분석했다. 각 방법론은 고유한 장단점을 가지며, 프로젝트의 성격, 팀의 규모, 그리고 최종 배포 환경에 따라 적합성이 달라진다.

6.1 방법론 비교 분석

아래 표는 세 가지 방법론을 다양한 평가 기준에 따라 종합적으로 비교 분석한 결과다. 이를 통해 개발자는 자신의 요구사항에 가장 부합하는 전략을 신속하게 판단할 수 있다.

6.2 주요 JetPack 버전에 따른 권장 NGC 컨테이너

실제 개발에서 가장 흔하게 발생하는 문제 중 하나는 호스트 JetPack 버전과 호환되지 않는 Docker 컨테이너 태그를 사용하는 것이다. 아래 표는 주요 JetPack 버전에 맞춰 NVIDIA가 공식적으로 제공하는 올인원 머신러닝 컨테이너(l4t-ml)의 권장 태그와 그 안에 포함된 핵심 패키지 버전을 정리한 실용적인 참조 자료다.

6.3 시나리오 기반 최종 권고

1. 빠른 프로토타이핑 및 간단한 스크립트 개발:

• 권장: venv

• 설명: 개인적인 학습이나 단일 파일 스크립트를 빠르게 테스트하는 목적이라면, venv가 가장 가볍고 신속한 선택이다. JetPack의 핵심 라이브러리 접근이 필요할 경우 --system-site-packages 플래그를 사용할 수 있으나, 이는 환경의 재현성을 포기하고 장기적으로 기술 부채(technical debt)를 생성하는 행위임을 명확히 인지해야 한다. 이 방법으로 개발된 결과물은 다른 환경으로 이식하거나 공유하기 매우 어렵다.

2. 복잡한 데이터 과학 및 학술 연구 프로젝트:

• 권장: Conda (Miniforge)

• 설명: 여러 버전의 파이썬 인터프리터가 필요하거나, conda-forge 채널을 통해 제공되는 특정 버전의 복잡한 과학 계산 라이브러리 스택에 의존하는 연구 프로젝트의 경우, Conda가 강력한 대안이 될 수 있다. 하지만 Conda 환경 내에서 CUDA 버전을 독립적으로 관리할 경우, 호스트 시스템의 L4T 커널 드라이버와의 미묘한 호환성 문제를 해결해야 할 수 있으므로, 시스템에 대한 깊은 이해가 요구된다.

3. 프로덕션 배포, 팀 협업, 완벽한 환경 복제가 요구되는 모든 프로젝트:

• 권장: Docker 컨테이너

• 설명: 이 시나리오에서 Docker는 선택이 아닌 필수다. Docker는 Jetson 개발에 필요한 안정성, 재현성, 이식성을 보장하는 유일하고 가장 강력한 방법이다. Dockerfile을 통해 개발 환경 전체를 코드로 관리함으로써, 팀원 모두가 동일한 환경에서 작업하고, CI/CD 파이프라인을 통해 테스트와 배포를 자동화하며, 수많은 엣지 디바이스에 일관된 소프트웨어를 안정적으로 배포할 수 있다. 이는 Jetson 기반의 AI 애플리케이션을 단순한 프로토타입에서 신뢰성 있는 상용 제품으로 전환하기 위한 핵심적인 MLOps 전략이다. NVIDIA NGC에서 제공하는 l4t-ml 컨테이너로 시작하여 필요한 부분을 커스터마이징하는 것이 가장 효율적인 접근 방식이다.

7. 참고 자료

1. NVIDIA L4T is a Linux based software distribution for the NVIDIA Jetson embedded computing platform. - NGC Catalog, https://catalog.ngc.nvidia.com/orgs/nvidia/containers/l4t-base
2. PyTorch GPU Not Detected on Jetson AGX Orin - NVIDIA Developer …, https://forums.developer.nvidia.com/t/pytorch-gpu-not-detected-on-jetson-agx-orin/326468
3. Updating Jetson AGX Orin with Jepack 5.1.2 to CUDA 11.8 and PyTorch installation from source, https://discuss.pytorch.org/t/updating-jetson-agx-orin-with-jepack-5-1-2-to-cuda-11-8-and-pytorch-installation-from-source/217761
4. Set Up Pytorch Environment on Nvidia Jetson Platform | by Rabinovich - Medium, https://medium.com/@yixiaozengprc/set-up-pytorch-environment-on-nvidia-jetson-platform-9eda291db716
5. Unable to install pytorch with cuda support on jetson AGX Xavier, https://forums.developer.nvidia.com/t/unable-to-install-pytorch-with-cuda-support-on-jetson-agx-xavier/279681
6. python - What are the risks of running ‘sudo pip’? - Stack Overflow, https://stackoverflow.com/questions/21055859/what-are-the-risks-of-running-sudo-pip
7. Python dependencies: break your system if you want - Jairo Andres Castañeda Pacheco, https://jairoandres.com/python-dependencies-break-your-system-if-you-want/
8. Is sudo pip install still a broken practice? - Ask Ubuntu, https://askubuntu.com/questions/802544/is-sudo-pip-install-still-a-broken-practice
9. How dangerous is using sudo pip? - python - Stack Overflow, https://stackoverflow.com/questions/63863328/how-dangerous-is-using-sudo-pip
10. How would you create and use a python virtual environment on a Jetson TX2, https://forums.developer.nvidia.com/t/how-would-you-create-and-use-a-python-virtual-environment-on-a-jetson-tx2/68462
11. Pip3 warning - Jetson Nano - NVIDIA Developer Forums, https://forums.developer.nvidia.com/t/pip3-warning/83188
12. Install packages in a virtual environment using pip and venv, https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/
13. Opencv Build with cuda on jetson agx orin for venv - Jetson AGX …, https://forums.developer.nvidia.com/t/opencv-build-with-cuda-on-jetson-agx-orin-for-venv/235553
14. Drawbacks of system-site-packages? - python - Stack Overflow, https://stackoverflow.com/questions/78106617/drawbacks-of-system-site-packages
15. Python virtualenv and venv dos and don’ts | by John Lee - Medium, https://jonny0211.medium.com/python-virtualenv-and-venv-dos-and-donts-abf1b83cf943
16. Python Virtual Environments: A Primer – Real Python, https://realpython.com/python-virtual-environments-a-primer/
17. Install Anaconda - All the Pythons for AI & ML! - JetsonHacks, https://jetsonhacks.com/2024/11/04/install-anaconda-all-the-pythons-for-ai-ml/
18. Upgrade Python on Jetson Nano - Tutorial - JetsonHacks, https://jetsonhacks.com/2023/06/12/upgrade-python-on-jetson-nano-tutorial/
19. conda-forge/miniforge: A conda-forge distribution. - GitHub, https://github.com/conda-forge/miniforge
20. Install Miniforge (Minimal conda installation) in Ubuntu arm64 / aarch64 - GitHub Gist, https://gist.github.com/elejke/3437be39478c66a3efac26700cb14334
21. Installing Python with Miniforge - Juan José García Ripoll, https://juanjose.garciaripoll.com/blog/installing-python-with-miniforge/index.html
22. Install Conda - MOOSE, https://mooseframework.inl.gov/ncrc/applications/ncrc_install_conda.html
23. GPU Support with PyTorch on Jetson Nano Using JetPack 4.6 and CUDA 10.2, https://discuss.pytorch.org/t/gpu-support-with-pytorch-on-jetson-nano-using-jetpack-4-6-and-cuda-10-2/214264
24. What are the correct docker base images to use? - NVIDIA Developer Forums, https://forums.developer.nvidia.com/t/what-are-the-correct-docker-base-images-to-use/327773
25. NVIDIA L4T TensorRT - NGC Catalog, https://catalog.ngc.nvidia.com/orgs/nvidia/containers/l4t-tensorrt
26. NVIDIA L4T TensorFlow - NGC Catalog, https://catalog.ngc.nvidia.com/orgs/nvidia/containers/l4t-tensorflow
27. NVIDIA L4T PyTorch - NGC Catalog, https://catalog.ngc.nvidia.com/orgs/nvidia/containers/l4t-pytorch
28. Get started on your AI journey quickly on Jetson. The Machine learning container contains TensorFlow, PyTorch, JupyterLab, and other popular ML and data science frameworks such as scikit-learn, scipy, and Pandas pre-installed in a Python environment. - NGC Catalog - NVIDIA, https://catalog.ngc.nvidia.com/orgs/nvidia/containers/l4t-ml
29. Question : Cuda version support · Issue #258 · dusty-nv/jetson-containers - GitHub, https://github.com/dusty-nv/jetson-containers/issues/258
30. Jetson with Docker - NVIDIA Developer Forums, https://forums.developer.nvidia.com/t/jetson-with-docker/303075
31. dusty-nv/jetson-containers: Machine Learning Containers for NVIDIA Jetson and JetPack-L4T - GitHub, https://github.com/dusty-nv/jetson-containers